Due to the rising virtualization of networks a multitude of different resource types may impact the data transmission additionally to the link bandwidth between different network nodes. In virtualized networks such as in a data center environment so-called network functions are decoupled from the physical hardware and are executed on virtual machines as virtual network functions instead. The granularity of such network functions and virtual machines is usually only limited by the hosting machines' memory resources and processing capabilities such that it would be possible to instantiate dedicated network functions for traffic.
However, this means that congestion or an insufficient quality of data transmission are also increasingly caused by resource bottlenecks which are caused by the performance of the networking functions, virtual machines or other entities, for example due to processing load, memory load, input/output interface or the like.
Another problem of the increasing heterogeneity and complexity of data networks is that the plurality of different types of resources may have a negative impact on the data transmission. For example in wireless and wired networks the resources used for data transmission are the main resource bottleneck. For instance in a wireless access network the shared radio spectrum needs to be distributed between transmitting and receiving user devices and traffic flows while in fixed access networks the capacity of a point-to-point link depends on the transmission medium such as fiber or copper lines or the like.
To overcome these problems the resources can be simply physically scaled up, for example by increasing a number of base stations or data center resources. However, this is often not a feasible option owing to the ever widening gap between an exponential increase in demand and the average revenue per user.
Conventional methods address the above mentioned problems by taking into account the utilization of queue resources as an indication of congestion. In general they are based on a coarse-grained end-to-end method for managing congestion due to high queue utilization. Congestion is explicitly notified towards the source nodes of a congested flow which in turn may typically scale down their respective throughputs in order to reduce the resource utilization and hence relief congestion.
Such a method is shown in the standard RFC 3168 specified by IETF named explicit congestion notification ECN. The explicit congestion notification ECN allows the mobile network nodes, i.e. in a GPRS/EPS network the gateway GPRS support node GGSN, the serving GPRS support node SGSN, the radio network controller RNC or the node B or in a EPS/LTE network the packet data network PGW, the serving network SGW or the evolved node eNB, or routers, switches or the like in the mobile backhaul/transport network to detect congestion by some random early detection RED process and then set the explicit congestion notification identification in the IP header of the user plane packets upon congestion.
According to the current specification of RFC 3168 the explicit congestion notification ECN is signaled to the data sink, i.e. the receiver which will upon receipt of the explicit congestion notification indication either try to downgrade the sending rate, for example by re-negotiating the media code in case of voice or multimedia communication, through application level control signaling or signal to the sender via transport protocol signaling that the network is congested, for example in TCP acknowledgements according to IETF RFC 5562.
However, the above mentioned conventional explicit congestion notification method has several shortcomings: Since it is an end-to-end communication, higher end-to-end latency will cause delay in taking control measures and have thereby an adverse impact on delay-sensitive and/or loss sensitive application flows. Another problem is that a coarse grained notification of congestion is provided as a simplistic binary indicating only the presence or absence of congestion but no other information such as the level and location of congestion, is available enabling a source node to control the sending rates.
According to RFC 3168 the explicit congestion notification information is provided by means of packet marking: Whenever the queue size exceeds a certain specified threshold the packet is marked. However it may be that even when the queue size is just below the corresponding congestion notification threshold the average waiting time of packets belonging to some delay-sensitive application are higher than what is required to meet the application quality of experience QoE requirement. The node is congested from the application perspective but a end node is not aware of it because the congestion notification information threshold has not been exceeded.
A further problem is that congestion is controlled in an uncoordinated and distributed way where each source node reduces the data rate of its respective flows according to some preconfigured value while remaining oblivious to the other flows sharing the same congested node. This leads in a non-optimal utilization of resources while throughput sensitive flows may get needlessly penalized by the congestion notification.
The above mentioned problems are addressed in U.S. Pat. No. 6,535,482 B1: A method is described wherein the congestion level or degree of congestion being experienced by flows is indicated to the source nodes upon the coarseness of the congestion notification. A congestion monitor determines a degree of congestion by a random early detection RED process and then notifies the source nodes via a separate ICMP Source Quench ISQ control packet generated by the corresponding congested router or node. Upon receiving the ISQ control packets the source node performs preemptive actions to reduce the level of congestion in proportion to the indicated congestion level or degree of congestion. The congested router also marks subsequent data packets by enabling the Congestion Experienced CE flag in order to prevent subsequent routers from sending ISQ control packets and hence reduces the signaling overhead. The packets are marked in proportion to a relative bandwidth used by each flow.
Further in U.S. Pat. No. 8,493,860 B2 a method of congestion detection and location is described in a radio access transport network. The radio access transport network comprises one or more network controllers each coupled with one or more radio base stations. Data packet flows are each associated with a mobile radio terminal communication and each flow is controlled by a corresponding flow control entity. The flows are monitored for congestion in the transport network. If a congestion area in the transport network is detected for one of the monitored data packet flows then a determination is made whether other monitored data packet flows share the detected congestion area. In such a case congestion notification information is communicated to the flow control entities corresponding to other monitored data packet flows sharing the detected congestion area. Based on the congestion notification information the informed flow control entities may take flow control actions. However, one of the problems is that congestion may only be detected within the radio access network. Further only the source nodes of the congested flows are notified for controlling congestion.
The aforementioned conventional methods and systems cause a high signaling load due to separate control packets for the congestion notification. Further the congestion notification is provided to the source nodes which may be distributed and which are usually not aware of quality of experience expectations of users. Another problem is that the congestion notification is sent only by routers closest to the source nodes or within the radio access network and the source nodes may not be aware of the highest level of congestion within the network resulting in a higher delay to mitigate congestion. An even further problem is that source nodes scale down their respective throughputs without taking into account quality of service or quality of experience requirements. Besides the method disclosed in U.S. Pat. No. 8,493,860 the location of the congestion is not known to the source nodes.